Microapp subscription recommendations

ABSTRACT

A system that comprises a microapp server includes a memory and at least one processor coupled to the memory. The microapp server is configured to generate a recommendation to modify a set of one or more subscribed microapps. The microapp server is configured to gather observational data that characterizes interactions of a user with an endpoint. The user is associated with the set of one or more subscribed microapps. The microapp server is further configured to identify, based on the observational data, a modification to the set of one or more subscribed microapps. The microapp server is further configured to send, to an administration console, the recommendation to modify the set of one or more subscribed microapps in accordance with the identified modification.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.15/931,747 (filed 14 May 2020), which is a continuation of InternationalApplication PCT/CN2020/084144 (filed 10 Apr. 2020). The entiredisclosure of both of these related applications is hereby incorporatedby reference herein.

BACKGROUND

A microapp is a lightweight software application that synchronizes datafrom one or more complex enterprise applications to provide a user withspecific, targeted functionality. Microapps provide a user with thisfunctionality in a streamlined manner via a relatively simple, containedinterface. Generally, a user can access the functionality provided by amicroapp without needing to launch a new application or toggle to adifferent application window. Microapps thus allow users to completesimple tasks within the context of an existing application environment,such as a web browser, a digital workspace, or other similar context.Microapps are often referred to as “cross-platform” softwareapplications because they typically execute within the context of anative application that serves as a container that isolates the microappfrom idiosyncrasies of different operating system platforms.

SUMMARY

In a first example implementation, a system that comprises a microappserver includes a memory and at least one processor coupled to thememory. The microapp server is configured to generate a recommendationto modify a set of one or more subscribed microapps. The microapp serveris configured to gather observational data that characterizesinteractions of a user with an endpoint. The user is associated with theset of one or more subscribed microapps. The microapp server is furtherconfigured to identify, based on the observational data, a modificationto the set of one or more subscribed microapps. The microapp server isfurther configured to send, to an administration console, therecommendation to modify the set of one or more subscribed microapps inaccordance with the identified modification. Some examples of the systemcan include features from one or more of the following implementations.

In a second example implementation, the microapp server is furtherconfigured to implement the recommendation in response to determiningthat an auto-subscription setting indicates that at least somerecommendations generated by the microapp server are to be implementedautomatically.

In a third example implementation, the administration console is hostedat the microapp server; and the administration console is configured todisplay the recommendation in a user interface before implementing therecommendation.

In a fourth example implementation, the observational data characterizesinteractions of a plurality of users with a corresponding plurality ofendpoints; the microapp server is further configured to identify a usergroup that includes the user, wherein each user included in the usergroup has associated therewith a corresponding set of one or moresubscribed microapps; and the recommendation is a recommendation tomodify each set of one or more subscribed microapps.

In a fifth example implementation, the observational data indicates thatthe user invoked a particular functionality using a managed application;identifying the modification includes identifying, based on theobservational data, a new microapp that provides the particularfunctionality; and the recommendation is a recommendation to add the newmicroapp to the set of one or more subscribed microapps.

In a sixth example implementation, identifying the modification includesidentifying, based on the observational data, an infrequently usedmicroapp that is included in the set of one or more subscribedmicroapps; and the recommendation is a recommendation to remove theinfrequently used microapp from the set of one or more subscribedmicroapps.

In a seventh example implementation, a method for identifying arecommended microapp comprises receiving, from an endpoint, at amicroapp server, observational data that characterizes interactionsbetween a user of the endpoint and an application. A particular one ofthe interactions causes the application to provide a particularfunctionality. The user is associated with a set of one or moresubscribed microapps. The method further comprises identifying, by themicroapp server, based on the observational data, a new microapp thatprovides the particular functionality. The method further comprisessending, to an administration console, a recommendation that the newmicroapp be added to the set of one or more subscribed microapps that isassociated with the user. Some examples of the method can includefeatures from one or more of the following implementations.

In an eighth example implementation, the method further comprisesupdating the set of one or more subscribed microapps to include the newmicroapp.

In a ninth example implementation, identifying the new microapp includesmaking a determination that the new microapp is not included in the setof one or more subscribed microapps.

In a tenth example implementation, the administration console is hostedat the microapp server.

In an eleventh example implementation, the recommendation is sent fromthe microapp server to the administration console via a network.

In a twelfth example implementation, the observational datacharacterizes interactions between a plurality of users and a pluralityof applications; and more than one of the plurality of users is observedto have invoked the particular functionality using the particularinteraction.

In a thirteenth example implementation, the observational datacharacterizes interactions between a plurality of users and a pluralityof applications; more than one of the plurality of users is observed tohave invoked the particular functionality using the particularinteraction; and identifying the new microapp includes determining thatthe particular interaction is observed at a frequency that is greaterthan a threshold frequency during a time period.

In a fourteenth example implementation, identifying the new microappincludes determining that the particular interaction is observed at afrequency that is greater than a threshold frequency.

In a fifteenth example implementation, identifying the new microappincludes determining that the particular interaction is one ofn-most-frequently observed interactions, n 10.

In a sixteenth example implementation, identifying the new microappincludes querying a microapp library for microapps that provide theparticular functionality.

In a seventeenth example implementation, the particular interactionincludes the user initially launching the application.

In an eighteenth example implementation, the observational data furthercharacterizes a number of times the user has used the application duringa time period.

In a nineteenth example implementation, a non-transitory computerreadable medium stores processor executable instructions to identify aninfrequently-used microapp. The processor executable instructionscomprise instructions to gather, at a microapp server, observationaldata that characterizes interactions between a user of an endpoint and aset of one or more subscribed microapps that is associated with theuser. The processor executable instructions comprise instructions toidentify, by the microapp server, based on the observational data, aninfrequently used microapp that is included in the set of one or moresubscribed microapps. The processor executable instructions compriseinstructions to send, to an administration console, a recommendationthat the infrequently used microapp be removed from the set of one ormore subscribed microapps that is associated with the user. Someexamples of the method can include features from one or more of thefollowing implementations.

In a twentieth example implementation, identifying the infrequently usedmicroapp further comprises making a determination that members of a usergroup that includes the user are not required to subscribe to theinfrequently used microapp.

In a twenty-first example implementation, the processor executableinstructions further comprise instructions to receive, from theadministration console, an indication that the set of one or moresubscribed microapps has been modified to exclude the infrequently usedmicroapp.

In a twenty-second example implementation, the processor executableinstructions further comprise instructions to update the set of one ormore subscribed microapps to exclude the infrequently used microapp.

BRIEF DESCRIPTION OF THE DRAWINGS

Various aspects of at least one example are discussed below withreference to the accompanying figures, which are not intended to bedrawn to scale. The figures are included to provide an illustration anda further understanding of the various aspects and are incorporated inand constitute a part of this disclosure. However, the figures are notintended as a definition of the limits of any particular example. Thefigures, together with the remainder of this disclosure, serve toexplain principles and operations of the described and claimed aspects.In the figures, each identical or nearly identical component that isillustrated is represented by a like reference numeral. For purposes ofclarity, every component may not be labeled in every figure.

FIG. 1 is a block diagram schematically illustrating selected data flowsthat are implemented in an example technique for managing microappsubscriptions for a user group.

FIG. 2 is a block diagram schematically illustrating selected componentsof an example framework for managing microapp subscriptions for a useror user group.

FIG. 3 is a flowchart illustrating an example method for generatingrecommendations to subscribe to new microapps and to unsubscribe frominfrequently used microapps.

FIG. 4 is a flowchart illustrating an example method for generatingrecommendations to subscribe to new microapps that provide functionalityassociated with applications that are frequently used by a user or usergroup.

FIG. 5 is a flowchart illustrating an example method for generatingrecommendations to terminate subscriptions for microapps that areinfrequently used by a user or user group.

DETAILED DESCRIPTION

As noted above, microapps provide a user with frequently-invokedfunctionality from a range of different applications via a relativelysimple, contained interface. Microapps accomplish this by synchronizingdata from a user's applications in a way that allows the user to accessdata and functionality provided by an underlying application withoutactually launching the underlying application or toggling to a differentinterface. User actions taken within a microapp serve as the basis forinputs provided to an underlying application. From a conceptualstandpoint, microapps can thus be understood as unbundling thefunctionality provided by a user's applications to provide the user withsimplified actions within the user's preferred working environment, suchas for example a web browser or digital workspace. Examples offrequently invoked actions that can be streamlined using microappsinclude approving expense reports, confirming calendar appointments,submitting helpdesk tickets, and reviewing vacation requests.

The wide-ranging productivity and usability benefits of microapps hasled to rapid growth in the number of available microapps. As a result,individual users may not be aware of the microapps which are mostrelevant to their frequently-invoked workflows. To address this,microapps are often deployed using a subscription model in which anadministrator grants individual users and/or user groups access to amicroapp by way of a managed subscription. Once a user is subscribed toa microapp, either via an individual subscription or membership in asubscribed user group, the user can access functionality and receivenotifications provided by the subscribed microapp. For example, in thecase of a user who works in the context of a digital workspace,subscribing the user to a particular microapp allows the user to accessfunctionality associated with the subscribed microapp via his/herdigital workspace. The subscription model, in principle, thus providesan efficient way to manage microapp usage in an organization, withparticular microapp functionality being deployed to relevant usersand/or user groups based their frequently invoked workflows. Thesubscription model also eliminates any need for individual users tomonitor the continually growing inventory of available microapps for newofferings that could be relevant to their individual workflows. Intheory, administrators will assume this responsibility.

However, as a practical matter, the subscription model relies on havingan administration team that is able to accurately and efficientlygenerate microapp subscriptions that are specifically tailored to theneeds of particular users and/or user groups. This administrationprocess remains heavily reliant on human knowledge and intuition. Forexample, to generate and manage useful microapp subscriptions,administrators should know how a user leverages his/her existingmicroapp subscriptions, what application functionality a user frequentlyinvokes, and what microapps are available to provide thatfrequently-invoked functionality. But administrators have imperfectknowledge of an organization's continually evolving workflows.Inevitably there will be microapps that, while providing functionalitythat members of a particular user group frequently invoke, are unknownto the relevant administration team that manages microapp subscriptionsfor the user group. Conversely, there will often exist subscribedmicroapps that, in fact, members of the user group use infrequently, ifat all. These circumstances represent an inefficient usage of resourcesand a lost opportunity to increase user productivity.

Beyond this, because microapp subscriptions are often administered touser groups, administrators should further be able to effectively defineuser groups that can benefit from a common suite of subscribedmicroapps. In a large organization it is difficult for administrators tocurate this individualized usage data across workgroups, thus presentingyet another obstacle to the efficient management of microappsubscriptions. This challenge increases as microapps become more popularand as their usage becomes more prevalent across an organization.

A more analytical approach to evaluating user activity would thereforestreamline administration of microapp subscriptions by reducing relianceon human knowledge and intuition, and in particular, on the judgmentand/or subjective assumptions of administrators. A more analyticalapproach to administering microapp subscriptions would reveal heretoforeunknown microapps that could provide functionality that addresses aparticular need of specific users and/or user groups. And a moreanalytical approach to managing user groups would allow user groups tobe defined based on the application functionality that is most ofteninvoked by individual users, thus allowing microapp subscriptions to bedeployed with increased efficiency.

In view of the foregoing, disclosed herein is a framework for managingmicroapp subscriptions for a user or user group. In certainimplementations such a framework provides the ability to analyticallygenerate recommendations to subscribe to new microapps that correspondto functionality provided by managed applications that are frequentlyused by a user or user group. In other implementations such a frameworkprovides the ability to analytically generate recommendations tounsubscribe from microapps that are infrequently used by a user or usergroup. In either case, such a framework allows microapp subscriptions tobe more closely aligned with the functionality that users and usergroups demand. This increases the efficiency of microapp deployment andreduces the administrative burden associated with manually trackingavailable microapps, tracking evolving user groups and workflows, andefficiently deploying microapp subscriptions across an organization. Italso builds user loyalty to particular microapps by seamlessly providinga user with access to microapps that are specifically tailored tohis/her needs. In certain applications, the techniques disclosed hereincan be implemented in an digital workspace that intelligently providesusers with microapps that are specifically tailored to theirfrequently-invoked workflows.

FIG. 1 is a block diagram schematically illustrating selected data flowsthat are implemented in an example technique for managing a collectionof subscribed microapps 312 for a user group 300. This example techniquebegins by sending application usage data from user group 300, and morespecifically from one or more endpoints 310 associated with user group300, to a microapp server 100. See Step 1 in FIG. 1. In this context,user group 300 comprises a plurality of users, each of which isassociated with at least one of the one or more endpoints 310. Anindividual user's association with an endpoint may exist by virtue of,for example, the user being logged into, authenticated to, or otherwiseusing the endpoint. While user group 300 is illustrated in FIG. 1 asincluding only four endpoints 310, it will be appreciated that usergroup 300 may include fewer or more endpoints in other implementations,and in general, may contain any suitable number of endpoints. Forexample, in an alternative embodiment, application usage can be analyzedand managed for individual users, in which case user group 300 could beunderstood as including as few as a single endpoint, at least in thecase where a particular user works with only a single endpoint.

Regardless of the number of endpoints included in user group 300, theapplication usage data characterizes how the users comprising user group300 interact with various applications, including for example “softwareas a service” (SaaS) applications, web applications, desktopapplications, proprietary applications, managed enterprise applications,unmanaged applications, and/or existing microapps to which members ofuser group 300 already subscribe. In some cases, the type of applicationbeing monitored may affect how the application usage data is gathered.For example, in the case of existing subscribed microapps, usage datacan be gathered directly at microapp server 100, thus eliminating anyneed to send usage data from endpoints 310. Additional details withrespect to how the application usage data is collected from the one ormore endpoints 310 will be provided in turn.

After receiving the application usage data, microapp server 100 analyzesthe application usage data and generates microapp recommendations. SeeStep 2 in FIG. 1. The microapp recommendations may includerecommendations to create one or more new microapp subscriptions 340and/or recommendations to unsubscribe from one or more of the existingsubscribed microapps 312. For example, the application usage data mayprovide insight into (a) which frequently-invoked functionalities lack acorresponding subscribed microapp, and (b) infrequently used microappsthat are nevertheless provided pursuant to a dedicated subscription. Themicroapp recommendations identify a particular microapp as well as aparticular user or user group for which the recommendation is made.Additional details with respect to how the microapp recommendations aregenerated will be provided in turn. These microapp recommendations areprovided to an administration console 200 that manages microappsubscriptions based on the recommendations received from microapp server100. See Step 3 in FIG. 1. Depending on its configuration,administration console 200 may in some cases automatically implement themicroapp recommendations, for example by automatically creating newmicroapp subscriptions 340 or automatically terminating existingmicroapp subscriptions. Alternatively, in other cases administrationconsole 200 may present the microapp recommendations to an administratorfor approval before actually implementing the recommendations.

Regardless of whether the microapp recommendations are implementedautomatically or with administrator approval, administration console 200communicates any subscription changes to microapp server 100. See Step 4in FIG. 1. Microapp server 100 then deploys the subscription changes touser group 300 by (a) sending user group 300 instructions for newmicroapp subscriptions 340 (see Step 5 a in FIG. 1), and/or (b) sendinguser group 300 instructions that identify infrequently used microapps(see Step 5 b in FIG. 1). Subscribed microapps 312 that are identifiedas being infrequently used can be considered as unsubscribed microapps350. Optionally, code and/or data associated with unsubscribed microapps350, if any, may be removed from the relevant endpoints 310. See Step 6in FIG. 1. Additional details with respect to how microapprecommendations are deployed from administration console 200 to microappserver 100 to members of user group 300 will be provided in turn.

A number of advantages may be derived from the various implementationsof the framework for managing microapp subscriptions described herein.For example, certain of the techniques disclosed herein rely oncollecting and analyzing application usage data from a large number ofusers working in a diverse range of usage contexts. Microapprecommendations that are developed based on this usage data do notnecessarily rely on the knowledge, intuition, or subjective evaluationof a human administrator. In particular, the resulting microapprecommendations are based on application usage patterns that could bedifficult or impossible for human analysts to identify. Certain of thetechniques disclosed herein also enable microapp recommendations to bespecifically tailored to a particular user group and the applicationusage patterns associated with that user group. Accurately managingmicroapp subscriptions may not be feasible for a human administrator,particularly in a large organization. The ability to provide users withsubscriptions to microapps that are closely tailored to their needs willultimately lead to improved user experience and productivity. Inparticular, by automatically providing a user with access to (that is,subscriptions to) microapps that provide that user's frequently-invokedfunctionality, this provides an improvement over existing systemswherein a useful microapp might remain unknown or otherwise hidden tothe user. Thus, certain of the implementations disclosed hereinautomatically provide users with access to those microapps that areclosely aligned with their frequently-invoked workflows.

As used herein, the term “microapp” refers, in addition to its ordinarymeaning, to a lightweight software application configured to provide auser with simplified access to specific functionality and/or data thatis provided by one or more underlying applications. For example,microapps allow a user to view information and perform actions withoutlaunching or switching context to a particular underlying application.Microapps streamline workflows by reducing context switching andeliminating the need to learn how to use complex applications. Microappsare often deployed using a subscription model in which an administratorgrants individual users and/or user groups access to a microapp by wayof a managed subscription. Once a user is subscribed to a microapp,either via an individual subscription or membership in a subscribed usergroup, the user can access functionality and receive notificationsprovided by the subscribed microapp.

System Architecture

FIG. 2 is a block diagram schematically illustrating selected componentsof an example framework for managing microapp subscriptions for a useror user group. The illustrated framework includes microapp server 100,which is capable of analyzing how a user interacts with variousapplications, such as subscribed microapps 312, managed applications314, and/or unmanaged applications 316. As used herein, the term “user”refers to a member of user group 300 who is associated with at least oneof the one or more endpoints 310, for example by virtue of the userbeing logged into, authenticated to, or otherwise using one of endpoints310. The framework illustrated in FIG. 2 further includes anadministration console 200 that is configured to manage and implementmicroapp subscriptions based on the recommendations generated bymicroapp server 100. Microapp server 100, administration console 200,and the one or more endpoints 310 communicate with each other via anetwork 500. Network 500 may be a public network (such as the Internet)or a private network (such as a corporate intranet or other network withrestricted access).

Other embodiments may have fewer or more communication paths, networks,subcomponents, and/or resources depending on the granularity of aparticular implementation. For example, in alternative implementationsthe functionality provided by microapp server 100 and administrationconsole 200 are provided by a single entity. Thus references to microappserver 100 and administration console 200 can be understood asencompassing a single entity that provides combined functionality. Moregenerally, it should be appreciated that the embodiments described andillustrated herein are not intended to be limited to the provision orexclusion of any particular services and/or resources. Likewise, whilethe number of different elements separately illustrated in FIG. 2 isreduced for clarity (see, for example, endpoints 310, subscribedmicroapp 312, managed application 314, and unmanaged application 316),it will be appreciated that, in general, the framework disclosed hereinis capable of analyzing application usage patterns, and managingmicroapp subscriptions, for any suitable number of endpoints andapplications.

Microapp server 100 is configured to generate microapp recommendationsby analyzing how users of the one or more endpoints 310 interact withtheir software applications. Microapp server 100 may comprise one ormore of a variety of suitable computing devices, such as a desktopcomputer, a laptop computer, a workstation, an enterprise-class servercomputer, a tablet computer, or any other device capable of supportingthe functionalities disclosed herein. A combination of different devicesmay be used in certain embodiments. As illustrated in FIG. 2, microappserver 100 includes one or more software modules configured to implementcertain of the functionalities disclosed herein as well as hardwarecapable of enabling such implementation.

The implementing hardware may include, but is not limited to, aprocessor 110, a memory 120, and any other suitable components thatenable microapp server 100 to interact with other components of themicroapp recommendation framework disclosed herein, or with human usersof such framework. Examples of such other components include, but arenot limited to, a communication hardware module, a bus and/orinterconnect, a display, a textual input device (such as a keyboard), apointer-based input device (such as a mouse), a microphone, and acamera. For example, a communications hardware module can include one ormore interfaces, or any appropriate network chip or chipset, that enablemicroapp server 100 to access a computer network such as a local areanetwork, a wide area network, a personal area network, or the Internetthrough a variety of wired and/or wireless connections, includingcellular connections.

Processor 110 can be implemented by one or more programmable processorsto execute one or more executable instructions, such as a computerprogram, to perform functions disclosed herein. As used herein, the term“processor” describes circuitry that performs a function, an operation,or a sequence of operations. The function, operation, or sequence ofoperations can be hard coded into the circuitry or soft coded by way ofinstructions held in memory 120 and executed by the processor circuitry.Processor 110 can perform the function, operation, or sequence ofoperations using digital values and/or using analog signals. In someexamples, processor 110 can be embodied in one or more applicationspecific integrated circuits, microprocessors, digital signalprocessors, graphics processing units, microcontrollers, fieldprogrammable gate arrays, programmable logic arrays, multicoreprocessors, or general-purpose computers with associated memory.Processor 110 can be analog, digital, or mixed. Processor 110 can be oneor more physical processors, which in some cases may be remotely locatedfrom microapp server 100. A processor that includes multiple processorcores and/or multiple processors can provide functionality for parallel,simultaneous execution of instructions or for parallel, simultaneousexecution of one instruction on more than one piece of data.

Memory 120 can be implemented using any suitable type of digitalstorage, such as one or more of a disk drive, a redundant array ofindependent disks, a flash memory device, or a random access memory(RAM) device. In certain embodiments memory 120 is used to storeinstructions that, when executed using processor 110, cause operationsassociated with the various modules described herein to be invoked.Memory 120 may include one or more types of RAM and/or a cache memorythat can offer a faster response time than a main memory.

The implementing software, on the other hand, may include, but is notlimited to, a microapp service 140, a functionality usage summarizer150, a recommendation generator 160, and any other suitable componentsthat enable microapp server 100 to perform the functionalities disclosedherein. Examples of such other components include, but are not limitedto, a communication software module and an operating system. Inparticular, a communication software module can include any appropriatenetwork software adaptor which allows for wired or wireless connectionto other components of microapp server 100 and/or to network 500. Thisenables microapp server 100 to communicate with other local and remotecomputing systems, services, and resources, examples of which includeadministration console 200 and the one or more endpoints 310. As anotherexample of implementing software, microapp server 100 may include anysuitable operating system. In general, the techniques provided hereincan be implemented without regard to the particular operating systemprovided in conjunction with microapp server 100, and therefore may alsobe implemented using any suitable existing or subsequently developedplatform.

Still referring to the example embodiment illustrated in FIG. 2,microapp service 140, functionality usage summarizer 150, andrecommendation generator 160 are each implemented using a non-transitorycomputer readable medium (such as memory 120) and one or more processors(such as processor 110) of a computing apparatus. In such embodimentsthe non-transitory computer readable medium stores program instructionsexecutable by the one or more processors to cause microapp server 100 toperform certain aspects of the techniques disclosed herein. Otherembodiments may have fewer or more modules depending on the granularityof a particular implementation.

For example, in certain embodiments microapp service 140 provides themicroapps and supporting services that enable a user to access data andfunctionality provided by one or more underlying applications. Examplesof underlying applications include, but are not limited to, SaaSapplications, web applications, desktop applications, proprietaryapplications, managed enterprise applications, and unmanagedapplications. Such applications can be hosted locally at one or more ofendpoints 310, or may provide functionality to endpoints 310 remotely,such as via an application server. Regardless of its particularimplementation, this framework allows a user to view information andperform actions without having to launch the underlying application ortoggle to a different interface. To this end, in certain embodimentsmicroapp service 140 includes a plurality of microservices 142 as wellas a microapp library 144 that stores the particular microapps. Forexample, in one implementation microapp service 140 is a single tenantservice that creates, manages, and provides implementing services tosupport the microapps stored in microapp library 144. This can beaccomplished through periodic communications with, and data acquisitionsfrom, the underlying applications. In some implementations, microapplibrary 144 is hosted locally at microapp server 100, such as in memory120, although in other implementations microapp library 144 is partiallyor wholly hosted in a networked storage repository.

Microapp service 140 includes one or more microservices 142 that provideimplementing functionality to support execution of the microapps storedin microapp library 144. For example, an active data cache microserviceis a single tenant service that can store configuration information andmicroapp data using a per-tenant database encryption key and per-tenantdatabase credentials. A credential wallet microservice can storeencrypted service credentials for the applications that underlie themicroapp functionality, as well as any required user authenticationtokens, such as OAuth2 tokens. A data integration provider microservicecan (a) interact with underlying applications to decrypt usercredentials and (b) communicate with underlying applications under theidentity of the user. Such communications use the user's actual accountto ensure that all actions are complaint with applicable data policies.A notification microservice processes notifications created in thecourse of interacting with the underlying applications. Notificationscan be stored in a database, served in a notification feed, and/ortransmitted as push notifications. A notification microserviceoptionally includes content controls that are configurable to restrictexposure of sensitive content. It will be appreciated that themicroservices described herein represent only a few examples ofmicroservices that support the creation, administration, and executionof the microapps stored in microapp library 144. Additional oralternative microservices may be included in microapp service 140 inother embodiments.

Referring again to FIG. 2, functionality usage summarizer 150 processesapplication usage data collected from the one or more endpoints 310. Theapplication usage data characterizes observed user interactions withthose applications that provide functionality at endpoints 310,including SaaS applications, web applications, desktop applications,proprietary applications, managed enterprise applications, unmanagedapplications, and/or subscribed microapps. Thus, as used herein, theterm “application usage data” should be understood as encompassing datathat characterizes a user's interactions with both conventionalapplications and microapps, subscribed or otherwise. In some cases theapplication usage data includes user profile data, thereby allowingobserved usage patterns to be associated with particular user groups.This allows, for instance, a list of the most frequently invokedapplication functionalities to be compiled for different user groups.This, in turn, provides insight into frequently invoked functionalitiesfor different user groups. User groups can be defined according to anysuitable characteristic, including for example work type, role, gender,age, and geolocation. In certain implementations functionality usagesummarizer 150 tracks the most (and least) frequently used microapps forindividual users and/or user groups, thereby providing insight into theparticular microapps that are most important for such users and/or usergroups.

The insights generated by functionality usage summarizer 150 can formthe basis for microapp recommendations generated by recommendationgenerator 160. For example, data characterizing frequently invokedfunctionalities and frequently (or infrequently) used microapps can bepassed to recommendation generator 160. In certain implementationsrecommendation generator 160 can be configured to provide microapprecommendations that administration console 200 (or an administratorusing administration console 200) can invoke. In some cases a microapprecommendation may comprise a recommendation that a particular user ormembers of a particular user group be granted a new subscription to amicroapp that would streamline functionality that is currently providedby a more complex enterprise application. In this case, microapprecommendation generator 160 will base its recommendation on theinventory of microapps available in microapp library 144, or in othermicroapp repositories, such as a cloud-based repository of availablemicroapps. For example, in one implementation recommendation generator160 is configured to send a query to a microapp repository, such asmicroapp library 144, to identify one or more microapps corresponding tofrequently invoked functionality. In other cases a microapprecommendation may comprise a recommendation that an existing microappsubscription be canceled, expired, or otherwise terminated for aparticular user or for members of a particular user group. In general,recommendation generator 160 can be understood a providing acomprehensive evaluation of which microapps should or should not begranted subscriptions for particular users and/or user groups.

Administration console 200 is configured to update microappsubscriptions based on recommendations received from microapp server100. Administration console 200 may comprise one or more of a variety ofsuitable computing devices, such as a desktop computer, a laptopcomputer, a workstation, an enterprise-class server computer, a tabletcomputer, or any other device capable of supporting the functionalitiesdisclosed herein. A combination of different devices may be used incertain embodiments. As illustrated in FIG. 2, administration console200 includes one or more software modules configured to implementcertain of the functionalities disclosed herein. These software modulesinclude, but are not limited to, a subscription manager 220 and a userinterface 240. Each of these subcomponents can be implemented using anon-transitory computer readable medium that stores program instructionsexecutable by a processor to cause administration console 200 to performcertain of the functionalities disclosed herein. Other embodiments mayhave fewer or more subcomponents depending on the granularity of aparticular implementation. In certain implementations administrationconsole 200 also hosts a repository of microapp subscription data 210and auto-subscription settings 230.

In an example implementation, subscription manager 220 is configured tomanage microapp subscriptions for individual users and for user groups.As described above, microapps are often deployed using a subscriptionmodel in which an administrator grants individual users and/or usergroups access to a microapp by way of a managed subscription. Anadministrator can use subscription manager 220 to manage suchdeployment. Subscription manager 220 leverages microapp subscriptiondata 210 which can be revealed via user interface 240. User interface240 can also be used to provide information to an administratorregarding the recommendations received from microapp server 100. Forexample, in some implementations recommendations are presented to anadministrator via user interface 240 for approval before implementation,while in other embodiments the recommendations are implementedautomatically. As illustrated in FIG. 2, administration console 200 canbe configured to store auto-subscription settings 230 that govern howadministration console 200 responds to recommendations received frommicroapp server 100. In some implementations auto-subscription settings230 are defined by a designated user, such as a user of administrationconsole 200. Regardless of how the recommendations are presented and/orimplemented by administration console 200, it will be appreciated thatsuch recommendations may include a recommendation to create a newmicroapp subscription and/or a recommendation to cancel, expire, orotherwise terminate an existing microapp subscription. More generally,because certain implementations of the microapp recommendation frameworkdisclosed herein use a subscription model to deploy microapprecommendations, this facilitates integration of this framework intoexisting microapp systems.

The microapp subscription management framework described herein isconfigured to manage microapp subscriptions for individual users and/oruser groups. Thus FIG. 2 illustrates user group 300 comprising aplurality of users, as represented by endpoints 310 to which the usersare authenticated. While user group 300 is illustrated in FIG. 2 asincluding six endpoints 310, it will be appreciated that user group 300may include fewer or more endpoints in other implementations, and ingeneral, may include any suitable number of endpoints. For example, inan alternative embodiment, application usage can be analyzed and managedfor individual users, in which case user group 300 would be understoodas including as few as a single endpoint, at least in the case where aparticular user works with only a single endpoint. Endpoints 310 areembodied in a computing device, examples of which include, but are notlimited to, a desktop computer, a laptop computer, a tablet computer,and a smartphone.

For example, in one implementation application usage across an entireorganization can be analyzed and managed. This can be accomplishedthrough the use of a domain application programming interface (API) thatallows all members of an organization to be identified. Application andmicroapp usage rates can then be determined by, for example, calculatinga ratio of a quantity of users who use a particular application ormicroapp to a total quantity of users in the organization. Thisfacilitates reporting that allows an administrator to quickly identifythose applications which are frequently used and those microapps whichare infrequently used. Segmenting the reporting based on identified usergroups further allows resulting microapp recommendations to be morespecifically targeted to certain segments of the organization.

Still referring to FIG. 2, example endpoint 310 can be understood ascomprising applications, including one or more subscribed microapps 312,one or more managed applications 314, and/or one or more unmanagedapplications 316. Endpoint 310 is also optionally configured to providea user with functionality provided by remotely-located applications,such as SaaS applications and web applications. Functionality associatedwith any other suitable existing or subsequently developed applicationscan be provided via the one or more endpoints 310 as well, includingproprietary applications and desktop applications. A user interacts withthe applications and microapps provided via the one or more endpoints310. It is these user interactions that are analyzed by microapp server100 and that ultimately form the basis for the generated microapprecommendations.

Managed applications 314 optionally include a hook 314′ that allowsapplication usage data to be harvested and provided to a data gatheringagent 318. In general, data gathering agent 318 detects interactionsbetween a user and the applications that the user accesses via endpoint310. This can be accomplished, for example, using any suitable existingor subsequently developed software that is capable of monitoring useractivity and compiling usage information that reflects the monitoredactivity. One example of such software is hook 314′ embedded in managedapplication 314. For example, in certain implementations hook 314′comprises an activity logger that generates a log of functionalityand/or commands that a user invokes in managed application 314.Likewise, in certain implementations data gathering agent 318 includes abrowser plugin that is capable of capturing interactions between a userand a web browser. In still other implementations hook 314′ isconfigured to detect each time an application or microapp is executed orinitially launched. In still other implementations hook 314′ isconfigured to record a total quantity of time that a user spendsinteracting with a particular application or microapp. To provide aspecific example, in certain embodiments the Citrix Mobile DeviceExperience (MDX) Toolkit, available from Citrix Systems, Inc. (Ft.Lauderdale, Fla.) is used to gather application usage data. In somecases hook 314′ and data gathering agent 318 track frequency ofapplication usage, for example to note how many times per hour, day,week, month, or other period that a particular application or microappis used. The particular data gathering technique invoked in a givenimplementation will depend on the type and capabilities of theapplication being monitored. Examples of monitored interactions include,but are not limited to, application or microapp launch interactions;authentication interactions; data entry interactions (including inputprovided via a pointing device or keyboard); data display and/or receiptinteractions; application context switching interactions; logoffinteractions; browser tab, page, and/or window close interactions;browser tab, page, and/or window open interactions; timeout detection;clipboard interactions (including cut, copy, and paste); and hypertexttransfer protocol command interactions.

Methodology—Overview

FIG. 3 is a flowchart illustrating an example method 3000 for generatingrecommendations to subscribe to new microapps and to unsubscribe frominfrequently used microapps. Method 3000 can be implemented, forexample, using the system architecture illustrated in FIG. 2 anddescribed herein, and in particular, using functionality provided by oneor more of microapp server 100, administration console 200, andendpoints 310. However other system architectures can be used in otherimplementations. To this end, the correlation of the variousfunctionalities shown in FIG. 3 to the microapp server 100,administration console 200, and endpoints 310 is not intended to implyany structural or use limitations. Rather, other implementations mayinclude, for example, varying degrees of integration wherein certainfunctionalities are effectively performed by different systems ormodules. For example, in an alternative implementation functionalityprovided by both microapp server 100 and administration console 200 areprovided by a single entity. Thus other implementations may have feweror more modules depending on the granularity of a particularimplementation. As can be seen, method 3000 includes a number of phasesand subprocesses, the sequence of which may vary from one implementationto another. However, when considered in the aggregate, these phases andsubprocess are capable of generating and deploying microapp subscriptionrecommendations based on observed user activity. These recommendationsmay include recommendations to create a new microapp subscription and/orrecommendations to terminate an existing microapp subscription.

Method 3000 starts with a data gathering agent 318 provided at endpoint310 monitoring how applications and/or microapps are used. See referencenumeral 3100 in FIG. 3. In certain embodiments where the activity ofmanaged application 314 is monitored, hook 314′ is embedded in managedapplication 314 and provides application usage data to data gatheringagent 318. As described above, data gathering agent 318 detectsinteractions between a user and the applications and/or microapps thatthe user accesses via endpoint 310. In certain implementations datagathering agent 318 compiles usage data in terms of frequency that aparticular application or microapp is used or otherwise active at agiven endpoint. In some cases data gathering agent 318 functions as abackground process that monitors activity at a given endpoint on anongoing basis, for example by recording such activity in a log file. Insome applications, where recommendations for new microapp subscriptionsare to be generated, data gathering agent 318 only monitors usage ofmanaged applications 314. In other applications, where recommendationsfor terminating existing microapp subscriptions are to be generated,data gathering agent 318 only monitors usage of subscribed microapps312. In still other applications, data gathering agent 318 monitorsusage of both managed applications 314 and subscribed microapps 312,with selected portions of the generated usage data being accessed lateraccording to the needs of a particular application. In still otherapplications, for example where recommendations for new microappsubscriptions are to be generated, data gathering agent 318 can beimplemented at microapp server 100, such a user's interactions withhis/her subscribed microapps are monitored remotely from the user'scorresponding endpoint.

Data gathering agent 318 is configured generate usage datacharacterizing the extent of a user's interactions with a wide varietyof different applications, including SaaS applications, webapplications, desktop applications, proprietary applications, managedenterprise applications, unmanaged applications, and/or existingmicroapps to which one or more users already subscribe. A wide varietyof techniques can be used to generate the usage data, includingtechniques that monitor particular user interactions with anapplication. Examples of such techniques are disclosed in PCT PatentApplication PCT/CN2020/081406 (filed 26 Mar. 2020), which is herebyincorporated herein by reference in its entirety. Such techniques allowidentification of discrete action sequences that characterize a user'sinteractions with a particular application, and thus such techniques canbe used to generate microapp subscription recommendations as disclosedherein. A wide range of existing instrumentation, telemetry, andbusiness insight generation platforms are capable of capturing userinteractions, one example of which is Citrix Insight Services providedby Citrix Systems, Inc. (Ft. Lauderdale, Fla.). In addition, while datagathering agent 318 is described here in terms of its operation at asingle particular endpoint, in general a plurality of data gatheringagents 318 will operate at a corresponding plurality of endpoints, thusallowing usage data characterizing how a large quantity of usersinteract with applications and microapps. This includes, in certainimplementations, most or substantially all of the users comprising agiven organization, as determined using a domain API. Optionally, thegathered usage data includes user profile data, thereby allowingobserved usage patterns to be associated with particular user groups.Data gathering agent 318 is further configured to send the resultingusage data to microapp server 100. See reference numeral 3200 in FIG. 3.

Upon receiving the usage data from endpoints 310, microapp server 100generates microapp subscription recommendations. In some cases, microappserver 100 analyzes application usage data (see reference numeral 3400in FIG. 3) and, based on such analysis, generates recommendations tosubscribe to new microapps (see reference numeral 3450 in FIG. 3).Additional details regarding the functionality provided by microappserver 100 to generate recommendations for subscribing to new microappsare provided in FIG. 4. In other cases, microapp server 100 analyzessubscribed microapp usage data (see reference numeral 3500 in FIG. 3)and, based on such analysis, generates recommendations to terminatesubscriptions for infrequently used microapps (see reference numeral3550 in FIG. 3). Additional details regarding the functionality providedby microapp server 100 to generate recommendations to terminatesubscriptions for infrequently used microapps are provided in FIG. 5.

Regardless of the particular type of recommendation generated bymicroapp server 100, such recommendations can be provided toadministration console 200. As described above, administration console200 is configured to manage microapp subscriptions based on therecommendations generated by microapp server 100. See reference numeral3600 in FIG. 3. Managing the microapp subscriptions may include, forexample, providing information to an administrator via user interface240 regarding the received recommendations. In some embodimentsrecommendations are presented to an administrator for approval beforeimplementation, while in other embodiments the recommendations areimplemented automatically. Either way, processing of the recommendationsis optionally governed by auto-subscription settings 230 stored atadministration console 200. Managing the microapp subscriptions mayfurther include using subscription manager 220 to update microappsubscription data 210 hosted at administration console 200.Administration console 200 is also optionally configured to sendinstructions to microapp server 100 to deploy updated subscriptioninformation to endpoints 310.

More specifically, microapp server 100 can be configured to sendsubscribe and/or unsubscribe instructions to endpoints 310. Seereference number 3700 in FIG. 3. Where a recommendation applies to auser group 300, the corresponding instructions can be broadcast to allendpoints included in the user group 300. The instructions may includeinstructions that create new microapp subscriptions 340 and/orinstructions that terminate existing subscriptions for infrequently usedmicroapps. Optionally, the instructions include instructions to removecode and/or data associated with unsubscribed microapps 350. In somecases users can be provided with a notification that a subscription hasbeen provided or a new microapp, or that an existing microappsubscription has been discontinued. In other cases the changes can beprovided in the background, for example with new microapp functionalitybeing made available at microapp server 100 without any positivenotification of such to users, for example, without any specificcommunication to endpoints 310. In certain embodiments a notification issent to administration console 200 indicating that either a new microappsubscription has been successfully created, or an existing microappsubscription has been successfully terminated.

Methodology—Generate Recommendation to Subscribe

FIG. 4 is a flowchart illustrating an example method 4000 for generatingrecommendations to subscribe to new microapps that provide functionalityassociated with applications that are frequently used by a user or usergroup. In certain implementations method 4000 functions as a backgroundprocess that continually or periodically monitors how users of one ormore endpoints 310 use the applications provided at the one or moreendpoints 310. In other implementations method 4000 can be triggered byan event such as an administrator command. Regardless of the trigger,method 4000 can be understood as beginning with gathering applicationusage data. See reference numeral 4110 in FIG. 4. For managedapplications, one way of gathering usage data is through the use of hook314′ that is embedded in, or that otherwise forms part of, managedapplication 314. Hook 314′ allows data gathering agent 318 to compileusage data in a way that is managed or otherwise controlled by anadministrator, such as an administrator that embeds hook 314′ into anorganization-wide deployment of managed application 314. In otherimplementations, the application use is monitored remotely, for exampleat an application server, thereby allowing usage data to be gatheredwithout direct communication with endpoints 310.

Application usage data can be quantified in terms of a frequency that aparticular application is used or otherwise active at a given endpoint.In some cases data gathering agent 318 is configured to track thefrequency with which an application is used, for example to create arecord of how many times per hour, day, week, month, or other periodthat the application is used, executed, or launched. In other cases datagathering agent 318 is configured to track a total quantity of time thata user spends interacting with a particular application. Other usagemetrics can be tracked in other implementations. In addition, usage of awide range of applications can be monitored, including both managed andunmanaged applications. A wide variety of techniques can be used togenerate such usage metrics, including techniques that monitorparticular user interactions with an application. Examples of suchtechniques are disclosed in PCT Patent Application PCT/CN2020/081406(filed 26 Mar. 2020), which is hereby incorporated herein by referencein its entirety. In a modified embodiment, usage data is gathered bymicroapp server 100 for a microapp that a user has accessed without asubscription, for example to provide insight into whether the usershould be granted a subscription to the microapp. Regardless of theparticular metric and application that are tracked, the gatheredapplication usage data can be transmitted to functionality usagesummarizer 150 via network.

Functionality usage summarizer 150 analyzes the received applicationusage data to identify one or more frequently used applications. Seereference numeral 4120 in FIG. 4. Application usage can be ranked usingany suitable measure, including frequency of application launch,frequency of application interaction, and total time using application.In certain implementations, one or more frequently used applications areidentified across an entire group of monitored users. However, in otherembodiments one or more frequently used applications are identified forone or more different user groups. The user groups may be definedaccording to any suitable classification, such as users in a particulardepartment, users having a particular job title or classification, usershaving a particular rank, users who perform a particular type of work,users having a particular gender, users falling within a particular agerange, and users working in a particular geographic region. Otherclassifications may be used in other embodiments. In some cases anadministrator defines the relevant classifications that will form thebasis for defining the user groups to be analyzed. This allows for thegeneration of, for example, a first listing of the n applications thatare most frequently used by men, and a second listing of the napplications that are most frequently used by women. In general, n is aninteger of any suitable value, for example, an integer between one andten.

For example, in one implementation frequently used applications can beidentified using the following framework:

Quantity Definition N_(T) the number of times a particular user uses aparticular application P_(T) the period of statistical analysis, forexample measured in minutes, hours, days, or the like$F_{AU} = \frac{N_{T}}{P_{T}}$ the frequency of application usage forthe particular user and the particular application, defined in terms ofa number of uses per unit time TH_(AU) a threshold of application usage,defined in terms of uses per unit time, above which a user is consideredto be a “frequent user” of an application; set as appropriate for agiven implementation N_(FA) a quantity of users who use the particularapplication with a frequency F_(AU) ≥ TH_(AU) (“frequent users”), suchthat for every user who uses the particular application with a frequencyF_(AU) ≥ TH_(AU), the quantity N_(FA) is increased by one N_(A) aquantity of users in a particular user group$P_{AP} = \frac{N_{FA}}{N_{A}}$ the fraction of users in the particularuser group who are “frequent users” of the particular applicationTH_(AP) a threshold fraction of “frequent users” in a user group, abovewhich the user group (as a whole) is considered as frequently using anapplication; set as appropriate for a given implementationAccording to this framework, the particular application can beconsidered to be a frequently used application for the particular usergroup (as a whole) if the fraction of users in the particular user groupwho are frequent users of the particular application (P_(AP)) is greaterthan or equal to the threshold TH_(AP), that is, when P_(AP)≥TH_(AP).Applying this framework to a quantity of applications observed to havebeen used by a particular user group allows a list of applicationssorted by popularity to be generated. This allows one or more frequentlyused applications to be identified for the user group. Where thisframework fails to identify at least one frequently used application, anotification can optionally be provided to an administrator havingauthority to adjust threshold parameters TH_(AU) and TH_(AP), thuspotentially making it easier to identify a frequently used application.Optionally one or more of threshold parameters TH_(AU) and TH_(AP) areautomatically adjusted in response to failure to identify at least onefrequently used application. In certain embodiments at least a portionof method 4000 is invoked for a plurality of identified frequently usedapplications.

Once one or more listings of frequently used applications are generated,functionality usage summarizer 150 can be configured to compare theseone or more listings with an existing listing of available microapps.This allows functionality usage summarizer 150 to make a determinationwith respect to whether a microapp exists that provides functionalityassociated with an identified frequently used application. See referencenumeral 4140 in FIG. 4. Functionality usage summarizer 150 mayoptionally submit a query to microapp library 144 to make suchdetermination. Such query may be submitted where microapp library 144includes information that links the functionality provided by a givenmicroapp with an application that also provides that same functionality.In an alternative implementation, functionality usage summarizer 150queries an index or other cross-reference table that enablesidentification of a microapp that provides functionality associated withan identified frequently used application. In some cases more than onemicroapp may be identified as corresponding to a given frequently usedapplication, while in other cases it may not be possible to identify anycorresponding microapp. Where multiple frequently used applications areidentified, regardless of whether for a single user group or forcorresponding multiple user groups, the search for a correspondingmicroapp can be performed for each of the multiple frequently usedapplications.

A wide range of monitoring techniques can be used to identify theparticular functionalities that users frequently invoke within bothmanaged and unmanaged applications. Examples of such techniques aredisclosed in PCT Patent Application PCT/CN2020/081406 (filed 26 Mar.2020), which is hereby incorporated herein by reference in its entirety.Such techniques can be used to generate microapp subscriptionrecommendations as disclosed herein. In general, such monitoringtechniques can be understood as identifying discrete action sequencesthat begin with a “start point” that is represented by a particular userinteracting with a particular application, and that end with an “endpoint” that is represented by a final interaction between the particularuser and the particular application. A wide variety of existing toolscan be used to identify the different types of interactions that mayform a discrete action sequence. For example, a login interaction, suchas a user authentication interaction using password authentication,biologic authentication, and/or peer authentication can be monitoredusing an identity management provider such as Okta, Inc. (San Francisco,Calif.). A wide range of existing instrumentation, telemetry, andbusiness insight generation platforms are capable of capturing a user'sbrowser activity, one example of which is Citrix Insight Servicesprovided by Citrix Systems, Inc. (Ft. Lauderdale, Fla.). A wide range ofbrowser plugins are also capable of detecting a user's browser activity.In general, any suitable existing or subsequently developed tools can beused to detect a start point, an end point, and intervening useractions. In addition, as noted above, a recorded log of user activitymay additionally or alternatively be used to detect and identifyrelevant user actions. Such a user activity log may be configured torecord any of the various actions disclosed herein, as well as otherrelevant actions, including user shortcut actions.

If it is determined that no microapp exists that provides functionalityassociated with an identified frequently used application, thenfunctionality usage summarizer 150 is optionally configured to reportthis potential demand for a new (that is, currently unavailable)microapp to administration console 200. See reference numeral 4145 inFIG. 4. For example, a notification identifying the frequently usedapplication can be generated in user interface 240. This informs theadministrator of an unmet demand, thus providing an opportunity todevelop or otherwise procure a new microapp that meets such demand. Suchreporting and notification may mark the end of processing for a givenfrequently used application, although other frequently used applicationscan be identified and processed according to method 4000.

On the other hand, if a microapp that provides functionality associatedwith an identified frequently used application is identified, thenfunctionality usage summarizer 150 can be configured to make adetermination with respect to whether the user (or user group) whofrequently uses the frequently used application already subscribes tothe identified microapp. See reference numeral 4150 in FIG. 4. This canbe accomplished, for example, by comparing the identified microapp to alist of subscribed microapps for the relevant user (or user group). Insome cases such a list may be stored at microapp server 100, while inother cases such a list can be stored at, and administered by,administration console 200. Where such list is not hosted at microappserver 100, a query may be transmitted to administration console 200 todetermine the subscription status of a given microapp. Optionally, anexact match is not required, such that if the relevant user (or usergroup) already subscribes to a microapp that provides substantiallysimilar functionality to the identified microapp, then this substantialsimilarity results in a conclusion that the relevant user (or usergroup) already subscribes to the identified microapp. In oneimplementation, substantial similarity is established when a designatedsimilarity measure exceeds a defined threshold.

If it is determined that the user (or user group) who frequently usesthe frequently used application already subscribes to the identifiedmicroapp, then functionality usage summarizer 150 is optionallyconfigured to report such an existing subscription to administrationconsole 200. See reference numeral 4155 in FIG. 4. Such reporting maymark the end of processing for a given frequently used application,although other frequently used applications can be identified andprocessed according to method 4000. On the other hand, if it isdetermined that the user (or user group) who frequently uses thefrequently used application has not already been granted a subscriptionto the identified microapp, then recommendation generator 160 can beconfigured to generate and send a subscription recommendation toadministration console 200. See reference numeral 4160 in FIG. 4. Such asubscription recommendation may include, for example, an identificationof the recommended microapp and the user (or user group) that should besubscribed to the identified microapp.

Subscription manager 220 can be configured to make a determination withrespect to whether received subscription recommendations are to beimplemented automatically. See reference numeral 4170 in FIG. 4. Suchdetermination can be made based on, for example, auto-subscriptionsettings 230 hosted at administration console 200. If subscriptionrecommendations are to be implemented automatically, subscription manger220 can be configured to automatically create a subscription for theuser (or user group) to the microapp corresponding to the identifiedfrequently used application. See reference numeral 4172 in FIG. 4. Onthe other hand, if subscription recommendations are not to beimplemented automatically, subscription manager 220 can be configured torecommend that the user (or user group) subscribe to the microappcorresponding to the identified frequently used application. Seereference numeral 4174 in FIG. 4. Such recommendation can be made, forexample, by displaying a notification to administrator via userinterface 240. Alternatively, user interface 240 can be configured todisplay a listing of recommended microapps for a particular user (oruser group), and administrator can create new subscriptions by makingselections from such listing. In either case, where auto-subscriptionfunctionality is disabled, it is ultimately left to the administrator tocreate the recommended microapp subscription. New microapp subscriptionscan be deployed to the relevant user (or user group) as illustrated inFIG. 3 and as described above. In certain embodiments a notification issent to administration console 200 indicating that a new microappsubscription has been successfully created. Administration console 200optionally updates microapp subscription data 210 as appropriate basedon the new subscriptions.

Methodology—Generate Recommendation to Terminate Subscription

FIG. 5 is a flowchart illustrating an example method 5000 for generatingrecommendations to terminate subscriptions for microapps that areinfrequently used by a user or user group. In certain implementationsmethod 5000 functions as a background process that continually orperiodically monitors how users of one or more endpoints 310 use theirsubscribed microapps 312. In other implementations method 5000 can betriggered by an event such as an administrator command. Regardless ofthe trigger, method 5000 can be understood as beginning with gatheringmicroapp usage data. See reference numeral 5110 in FIG. 5. In some casesone or more of subscribed microapps 312 include code that automaticallyrecords and/or reports usage data, such as how often the microapp isactually executed at a particular endpoint. In other cases microappusage data is compiled at microapp server 100, for example by one ormore of microservices 142 that provide dedicated usage tracking. In suchcases each time an endpoint executes a particular subscribed microapp,such execution can be recorded by, for example, a usage trackingmicroservice. Here, gathering the microapp usage data may comprisesubmitting a query to microapp server 100 to acquire particular microappusage data. Is still other cases a combination of these approaches maybe used, with certain microapp usage data being maintained at endpoints310, while other such data is maintained at microapp server 100.

Microapp usage data can be quantified in terms of a frequency that aparticular subscribed microapp is used, executed, or otherwise active ata given endpoint. Such frequency can be expressed in terms of a numberof executions per hour, day, week, month, or other relevant time period.In other cases a total quantity of time that a user spends interactingwith a particular subscribed microapp is tracked. Still other usagemetrics can be tracked in other implementations. Regardless of theparticular metric tracked, the gathered microapp usage data can betransmitted to functionality usage summarizer 150 via network.

Functionality usage summarizer 150 analyzes the received subscribedmicroapp usage data to identify one or more infrequently used microapps.See reference numeral 5120 in FIG. 5. Microapp usage data can be rankedby using any suitable measure, including frequency of microappexecution, frequency of microapp interaction, and total time usingmicroapp. In certain implementations, one or more infrequently usedmicroapps are identified across an entire group of monitored users.However, in other embodiments one or more infrequently used microappsare identified for one or more different user groups. The user groupsmay be defined according to any suitable classification, such as usersin a particular department, users having a particular job title orclassification, users having a particular rank, users who perform aparticular type of work, users having a particular gender, users fallingwithin a particular age range, and users working in a particulargeographic region. Other classifications may be used in otherembodiments. In some cases an administrator defines the relevantclassifications that will form the basis for defining the user groups tobe analyzed. This allows for the generation of, for example, a firstlisting of the n applications that are least frequently used by men, anda second listing of the n applications that are least frequency used bywomen. In general, n is an integer of any suitable value, for example,an integer between one and ten.

For example, in one implementation infrequently used microapps can beidentified using the following framework:

Quantity Definition N_(M) the number of times a particular user uses aparticular microapp P_(M) the period of statistical analysis, forexample measured in minutes, hours, days, or the like$F_{MU} = \frac{N_{M}}{P_{M}}$ the frequency of microapp usage for theparticular user and the particular microapp, defined in terms of anumber of uses per unit time TH_(MU) a threshold of microapp usage,defined in terms of uses per unit time, above which a user is consideredto be a “frequent user” of a microapp; set as appropriate for a givenimplementation N_(FM) a quantity of users who use the particularmicroapp with a frequency F_(MU) > TH_(MU) (“frequent users”); users whouse the particular microapp with a frequency F_(MU) ≤ TH_(MU)(“infrequent users”) are not included in the quantity N_(FM) N_(A) aquantity of users in a particular user group$P_{MP} = \frac{N_{FM}}{N_{A}}$ the fraction of users in the particularuser group who are “frequent users” of the particular microapp TH_(MP) athreshold fraction of “frequent users” in a user group, below which theuser group (as a whole) is considered as infrequently using a microapp;set as appropriate for a given implementationAccording to this framework, the particular microapp can be consideredto be an infrequently used microapp for the particular user group (as awhole) if the fraction of users in the particular user group who arefrequent users of the particular microapp (P_(MP)) is less than or equalto the threshold TH_(MP), that is, when P_(MP)≤TH_(MP). Applying thisframework to a quantity of microapps observed to have been used by aparticular user group allows a list of microapps sorted by popularity tobe generated. This allows one or more infrequently used microapps to beidentified for the user group. Where this framework fails to identify atleast one infrequently used microapp, a notification can optionally beprovided to an administrator having authority to adjust thresholdparameters TH_(MU) and TH_(MP), thus potentially making it easier toidentify infrequently used microapps. Optionally one or more ofthreshold parameters TH_(MU) and TH_(MP) are automatically adjusted inresponse to failure to identify at least one infrequently used microapp.In certain embodiments at least a portion of method 5000 is invoked foreach one of a plurality of identified infrequently used microapps.

Once usage data for subscribed microapps 312 is gathered, adetermination can be made with respect to whether any infrequently usedmicroapps can be identified. See reference numeral 5140 in FIG. 5. Sucha determination can be made, for example, by analyzing a microapplisting that is sorted by microapp popularity. In some cases separatesorted listings for different use groups can be generated and analyzed.If functionality usage summarizer 150 fails to identify any infrequentlyused microapps, either for individual users or established user groups,this failure is optionally reported to administration console 200. Seereference numeral 5145 in FIG. 5. For example, in certainimplementations a notification indicating that no infrequently usedmicroapps can be identified is generated in user interface 240. Thisinforms an administrator that existing microapp subscriptions can beconsidered to be efficiently deployed. Such reporting and notificationmay mark the end of processing at a given time, although additionalprocessing according to method 5000 may be performed at a different timeand/or for different users or user groups.

If an infrequently used microapp is identified, a determination can bemade with respect to whether the user (or user group) who infrequentlyuses the microapp is required to subscribe to the identifiedinfrequently used microapp. See reference numeral 5150 in FIG. 5. Thiscan be accomplished, for example, by comparing the identifiedinfrequently used microapp to a list of required microapps for therelevant user (or user group). In some cases such a list may be storedat microapp server 100, while in other cases such a list can be storedat, and administered by, administration console 200. Where such list isnot hosted at microapp server 100, a query may be transmitted toadministration console 200 to determine the subscription requirementsfor a given user (or user group). If it is determined that the user (oruser group) who infrequently uses the microapp is required to subscribeto this microapp, this situation is optionally reported toadministration console 200. See reference number 5155 in FIG. 5. Forexample, in certain implementations a notification identifying theinfrequently used microapp and the user (or user group) subject to thesubscription requirement is generated in user interface 240. This mayprompt the administrator to reevaluate the subscription requirement todetermine if it is appropriate given that, in actuality, the user (oruser group) infrequently uses the subject microapp.

On the other hand, if it is determined that the user (or user group) whoinfrequently uses the microapp is not required to subscribe to theidentified infrequently used microapp, then recommendation generator 160can be configured to generate and send an unsubscribe recommendation toadministration console 200. See reference numeral 5160 in FIG. 5. Suchan unsubscribe recommendation may include, for example, anidentification of the infrequently used microapp and the user (or usergroup) that does not require a subscription to the identified microapp.In response, subscription manager 220 can be configured to make adetermination with respect to whether received unsubscriberecommendations are to be implemented automatically. See referencenumeral 5170 in FIG. 5. Such determination can be made based on, forexample, auto-subscription settings 230 hosted at administration console200. If unsubscribe recommendations are to be implemented automatically,subscription manager 220 can be configured to automatically implementthe unsubscribe recommendation for the infrequently used microapp in anysuitable way, such as by affirmatively cancelling the subscription or bypassively marking it for expiration or nonrenewal. See reference numeral5172 in FIG. 5.

If unsubscribe recommendations are not to be implemented automatically,subscription manager 220 can be configured to recommend that the user(or user group) be unsubscribed from the infrequently used microapp. Seereference numeral 5174 in FIG. 5. Such recommendation can be made, forexample, by displaying a notification to administrator via userinterface 240. Alternatively, user interface 240 can be configured todisplay a listing of existing microapp subscriptions that arerecommended for termination, and the administrator can terminate suchsubscriptions by making selections from such listing. In either case,where auto-subscription functionality is disabled, it is ultimately leftto the administrator to terminate subscriptions as deemed appropriate.Optionally, instructions may be sent to endpoints 310 to remove codeand/or data associated with unsubscribed microapps 350.

Regardless of whether unsubscribe instructions are to be implementedautomatically or manually, such instructions can be transmitted fromadministration console 200 to microapp server 100, with the microappserver 100 deploying instructions, if any, to the affected endpoints310. In other implementations, such instructions can be transmitteddirectly from administration console 200 to affected endpoints 310. Instill other implementations, subscriptions can be terminated at microappserver 100, thus eliminating any need for further deployment toendpoints 310. In this case, endpoints 310 may be restricted fromaccessing functionality associated with unsubscribed microapps 350 atmicroapp server 100. In certain embodiments a notification is sent toadministration console 200 indicating that an existing microappsubscription has been successfully terminated. Administration console200 optionally updates microapp subscription data 210 as appropriatebased on the terminated subscriptions.

CONCLUSION

The foregoing description and drawings of various embodiments arepresented by way of example only. These examples are not intended to beexhaustive or to limit the invention to the precise forms disclosed.Alterations, modifications, and variations will be apparent in light ofthis disclosure and are intended to be within the scope of the inventionas set forth in the claims. In addition, the phraseology and terminologyused herein is for the purpose of description and should not be regardedas limiting. Any references to examples, components, elements, or actsof the systems and methods herein referred to in the singular can alsoembrace examples including a plurality. Likewise, any references inplural to any example, component, element or act herein can also embraceexamples including only a singularity. References in the singular orplural form are not intended to limit the presently disclosed systems ormethods, their components, acts, or elements. The use herein of“including”, “comprising”, “having”, “containing”, “involving”, andvariations thereof is meant to encompass the items listed thereafter andequivalents thereof as well as additional items. References to “or” canbe construed as inclusive so that any terms described using “or” canindicate any of a single, more than one, and all of the described terms.

We claim:
 1. A non-transitory computer readable medium storing processorexecutable instructions to identify an infrequently-used subscribedmicroapp, the processor executable instructions comprising instructionsto: gather, at a microapp server, observational data that characterizesinteractions between a user of an endpoint and a set of one or moresubscribed microapps that is associated with the user, wherein the userbelongs to a user group, and wherein the user is subject to arequirement to subscribe to microapps included in a list of requiredmicroapps; identify, by the microapp server, based on the observationaldata, an infrequently used microapp that is included in the set of oneor more subscribed microapps; make a determination that the infrequentlyused microapp is not included in the list of required microapps; andsend, to an administration console, a recommendation that theinfrequently used microapp be removed from the set of one or moresubscribed microapps that is associated with the user.
 2. Thenon-transitory computer readable medium of claim 1, wherein identifyingthe infrequently used microapp includes determining that the userinteracts with the infrequently used microapp with a frequency that isless than a threshold frequency during a time period.
 3. Thenon-transitory computer readable medium of claim 1, wherein: theobservational data characterizes interactions of a plurality of userswith a corresponding plurality of endpoints, at least some of the usersbelonging to the user group; at least some users in the user group havea corresponding set of one or more subscribed microapps; and therecommendation is a recommendation that any users in the user group whohave a subscription to the infrequently used microapp have suchsubscription terminated.
 4. The non-transitory computer readable mediumof claim 1, wherein: the administration console is hosted at themicroapp server; and the administration console is configured to displaythe recommendation in a user interface before implementing therecommendation.
 5. The non-transitory computer readable medium of claim1, the processor executable instructions further comprising instructionsto receive, from the administration console, an indication that the setof one or more subscribed microapps has been modified to exclude theinfrequently used microapp.
 6. The non-transitory computer readablemedium of claim 1, the processor executable instructions furthercomprising instructions to update the set of one or more subscribedmicroapps to exclude the infrequently used microapp.
 7. Thenon-transitory computer readable medium of claim 1, wherein theadministration console is configured to implement the recommendation inresponse to determining that an auto-update setting indicates that atleast some recommendations generated by the microapp server are to beimplemented automatically.
 8. A system that comprises a microapp serverthat includes a memory and at least one processor coupled to the memory,wherein the microapp server is configured to: gather, at the microappserver, observational data that characterizes interactions between auser of an endpoint and a set of one or more subscribed microapps thatis associated with the user, wherein the user belongs to a user group,and wherein the user is subject to a requirement to subscribe tomicroapps included in a list of required microapps; identify, by themicroapp server, based on the observational data, an infrequently usedmicroapp that is included in the set of one or more subscribedmicroapps; make a determination that the infrequently used microapp isnot included in the list of required microapps; and send, to anadministration console, a recommendation that the infrequently usedmicroapp be removed from the set of one or more subscribed microappsthat is associated with the user.
 9. The system of claim 8, whereinidentifying the infrequently used microapp includes determining that theuser interacts with the infrequently used microapp with a frequency thatis less than a threshold frequency during a time period.
 10. The systemof claim 8, wherein: the observational data characterizes interactionsof a plurality of users with a corresponding plurality of endpoints, atleast some of the users belonging to the user group; at least some usersin the user group have a corresponding set of one or more subscribedmicroapps; and the recommendation is a recommendation that any users inthe user group who have a subscription to the infrequently used microapphave such subscription terminated.
 11. The system of claim 8, wherein:the administration console is hosted at the microapp server; and theadministration console is configured to display the recommendation in auser interface before implementing the recommendation.
 12. The system ofclaim 8, wherein the microapp server is further configured to receive,from the administration console, an indication that the set of one ormore subscribed microapps has been modified to exclude the infrequentlyused microapp.
 13. The system of claim 8, wherein the microapp server isfurther configured to update the set of one or more subscribed microappsto exclude the infrequently used microapp.
 14. The system of claim 8,wherein the administration console is configured to implement therecommendation in response to determining that an auto-update settingindicates that at least some recommendations generated by the microappserver are to be implemented automatically.
 15. A method for identifyingan infrequently-used subscribed microapp, the method comprising:gathering, at a microapp server, observational data that characterizesinteractions between a user of an endpoint and a set of one or moresubscribed microapps that is associated with the user, wherein the userbelongs to a user group, and wherein the user is subject to arequirement to subscribe to microapps included in a list of requiredmicroapps; identifying, by the microapp server, based on theobservational data, an infrequently used microapp that is included inthe set of one or more subscribed microapps; making a determination thatthe infrequently used microapp is not included in the list of requiredmicroapps; and sending, to an administration console, a recommendationthat the infrequently used microapp be removed from the set of one ormore subscribed microapps that is associated with the user.
 16. Themethod of claim 15, wherein identifying the infrequently used microappincludes determining that the user interacts with the infrequently usedmicroapp with a frequency that is less than a threshold frequency duringa time period.
 17. The method of claim 15, wherein: the administrationconsole is hosted at the microapp server; and the administration consoleis configured to display the recommendation in a user interface beforeimplementing the recommendation.
 18. The method of claim 15, furthercomprising receiving, from the administration console, an indicationthat the set of one or more subscribed microapps has been modified toexclude the infrequently used microapp.
 19. The method of claim 15,further comprising updating the set of one or more subscribed microappsto exclude the infrequently used microapp.
 20. The method of claim 15,wherein the administration console is configured to implement therecommendation in response to determining that an auto-update settingindicates that at least some recommendations generated by the microappserver are to be implemented automatically.